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ABSTRACT 


Current  fault  simulation  techniques  such  as  concurrent,  deductive, 
and  parallel  fault  simulation  are  not  powerful  enough  for  today's  very 
large  integrated  circuit  designs.  More  powerful  fault  simulation  tech¬ 
niques  are  needed  to  prevent  a  crisis  in  integrated  circuit  testing.  A 
new  simulation  technique  based  on  the  well-known  concurrent  find  deduc¬ 
tive  techniques  is  presented,  which  uses  a  hierarchical  representation 
of  the  circuit  design  and  unlike  the  traditional  Implementations  of 
these  techniques  does  not  expand  the  circuit  to  a  single,  lowest  level, 
description.  The  simulation  technique  is  shown  to  be  decoupled  from  the 
fault  model  of  the  oireuit  through  the  use  of  fault  libraries.  These 
libraries  are  based  on  the  principle  that  any  detectable  fault  will 
cause  an  erroneous  output  value  for  some  input  vector.  The  implementa¬ 
tion  of  this  technique  is  described  and  preliminary  performance  results 
are  given.  The  advantages  and  disadvantages  of  this  technique  are  dis¬ 
cussed  and  possible  enhancements  are  described. 
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1 .  INTRODUCTION 


Simulation  is  the  technique  of  approximating  the  response  of  a  sys¬ 
tem  to  a  stimulus  by  evaluating  a  model  of  the  system.  The  accuracy  of 
the  model  determines  how  closely  the  simulation  approximates  the  actual 
system  and  greater  accuracy  is  usually  more  expensive  in  terms  of  com¬ 
puter  time  and  space.  When  the  computation  time  becomes  unacceptably 
long,  or  the  space  requirements  exceed  the  capabilities  of  the  computer, 
simulation  becomes  impractical.  The  alternatives  to  this  situation  are: 
use  a  larger,  faster  computer;  reduce  the  computational  requirements  by 
simplifying  the  models;  break  the  system  into  smaller  pieces  and  simu¬ 
late  each  piece  separately;  or  use  more  efficient  algorithms. 

The  first  approach,  using  larger,  faster  computers,  is  practical  in 
some  instances,  but  many  simulation  algorithms  show  second  order  effects 
(or  worse)  [1,2]  in  time  and  space  so  a  machine  four  times  "bigger" 
would  be  required  to  simulate  a  system  only  twice  as  large.  Clearly 
this  is  an  expensive  solution,  and  many  problems  exist  which  cannot  be 
simulated  on  any  machine  in  existence  today. 

The  second  approach,  simplifying  the  models,  has  been  successful, 
but  it  involves  trading  accuracy  for  speed  and  space.  A  typical  example 
of  this  method  is  using  logic  simulation  instead  of  circuit  simulation 
to  simulate  large,  integrated  circuit  designs.  Circuit  simulators  can 
handle  on  the  order  of  100  transistors  [ 33 *  while  logic  simulation  can 
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handle  several  thousand  transistor  circuits.  The  tradeoff  is  reduced 
accuracy  of  signal  values,  and  in  some  designs  may  yield  values  that  are 
wrong.  The  user  of  a  simulator  must  be  aware  of  the  limitations  imposed 
by  simulation  models  and  stay  well  within  these  limitations  to  avoid 
incorrect  results.  Since  very  few  physical  systems  can  be  modelled  per¬ 
fectly,  this  is  a  fundamental  problem  in  simulation,  and  the  user  should 
always  check  the  results  of  a  simulation  for  validity.  The  accuracy 
versus  speed  and  space  problem  has  led  to  the  development  of  multi-mode 
simulation  where  circuit  simulation  (most  expensive)  is  used  for  criti¬ 
cal  timing  paths,  logic  simulation  (less  expensive)  is  used  for  other 
circuitry  directly  interacting  with  the  critical  path,  and  functional 
simulation  (least  expensive)  for  the  remaining  parts  of  the  system  [4]. 

The  third  approach,  partitioning  the  circuit,  can  be  difficult  and 
tedious  for  the  user  [5,6,7].  In  cases  where  the  simulation  algorithm 
is  at  least  O(n^),  partitioning  may  dramatically  increase  throughput  by 
reducing  the  number  of  primitives  the  algorithm  deals  with  at  any  one 
time.  That  is,  a  large  is  much  greater  than  the  sum  of  its  squared 
factors.  Even  for  a  linear  algorithm,  if  the  circuit  is  so  large  that 
frequent  page  faults  seriously  degrade  the  performance  of  the  simulator, 
partitioning  can  improve  throughput  by  reducing  the  page  fault  rate,  but 
the  total  amount  of  work  required  to  evaluate  the  circuit  primitives 
remains  unchanged.  Manual  partition!  g  is  a  poor  means  of  fitting  the 
circuit  to  the  simulator,  because  it  is  tedious  and  error  prone. 


The  final  approach,  using  more  efficient  algorithms,  can  be  viewed 
as  the  evolution  of  a  particular  style  of  simulation.  For  example,  the 
earliest  fault  simulations  were  done  with  logic  simulators  and  the 
faults  were  injected  by  manually  altering  the  system  being  tested  [8]. 
Fault  simulation  quickly  evolved  to  specialized  simulators  that  automat¬ 
ically  injected  the  faults,  and  then  to  more  efficient  algorithms  for 
perfo.  ing  this  simulation.  This  evolution  led  to  the  parallel  simula¬ 
tor  which  provided  tremendous  speedup  by  simulating  several  closely 
related  machines  at  the  same  time.  Parallel  simulation  is  still  a  popu¬ 
lar  simulation  technique.  From  parallel  simulation,  deductive  [9]  and 
concurrent  [10]  simulation  were  the  next  major  developments  in  fault 
simulation  algorithms.  These  techniques  are  fundamentally  different 
from  parallel  simulation  because  they  determine  all  detectable  faults  in 
the  system,  for  a  particular  input  vector,  in  one  pass  instead  of  many 
passes.  These  techniques  have  been  the  subject  of  current  research  and 
development  in  fault  simulation  and  are  becoming  quite  popular  in  indus¬ 
try.  Experience  has  shown  that  these  techniques  are  more  efficient  on 
large  systems  than  parallel  simulation,  but  they  require  much  more 
memory  [11].  Since  the  price  of  computer  memory  is  decreasing  rapidly, 
concurrent  and  deductive  fault  simulation  techniques  are  steadily  becom¬ 
ing  more  attractive. 

1.1.  Terminology 

A  failure  is  a  defect  which  if  present  in  the  circuit  may,  under 
the  appropriate  conditions,  cause  the  circuit  to  behave  incorrectly. 


The  description  of  the  effect  of  this  failure  at  some  level  of  abstrac¬ 
tion  is  called  a  fault.  The  incorrect  behavior  of  the  fault  is  called 
an  error.  The  term  fault  is  often  used  interchangeably  in  the  litera¬ 
ture  where  error  is  really  meant.  Errors  are  said  to  propagate  (through 
a  module)  when  the  error  presented  at  the  input  to  the  module  causes  an 
incorrect  response  (error)  at  the  outputs  of  the  module.  If  no 
incorrect  response  is  generated ,  then  the  error  is  said  to  be  absorbed 
or  blocked.  If,  for  the  input  stimulus  and  a  particular  fault,  no  error 
is  produced  at  the  primary  outputs,  then  that  fault  is  undetectable 
under  the  current  input.  In  the  case  of  sequential  circuits,  the 
current  and  all  previous  inputs  must  be  considered.  If  the  fault 
remains  undetectable  for  all  possible  input  stimuli,  then  the  fault  is 
an  undetectabl'e  fault. 

There  are  two  intrinsic  tasks  which  a  fault  simulator  must  perform: 
fault  activation  and  fault  propagation.  Activation  is  the  process  of 
deciding  which  internal  faults  can  affect  the  outputs  of  a  module,  given 
the  input  stimulus,  and  propagation  is  the  process  of  deciding  if  the 
faults  present  at  the  inputs  of  a  module  can  be  detected  at  the  outputs 
of  the  module.  The  activation  process  used  by  the  author  is  based  on  a 
table  lookup  technique  and  is  described  in  Chapter  3- 

1.2.  Research  Goals 

We  believe  that  the  use  of  hierarchy  wherever  possible  is  important 
to  improve  simulator  performance  in  several  ways.  The  hierarchical 
representation  of  a  system  is  more  compact,  which  helps  increase  the 
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size  of  the  system  that  can  be  simulated.  This  hierarchical  representa¬ 
tion  also  allows  the  user  to  control  the  complexity  of  the  simulation  by 
controlling  the  complexity  of  the  system  description  [12].  The 
hierarchical  description  of  a  system  also  affords  different  perspectives 
of  the  system  which  are  difficult  to  obtain  from  a  flat  system  descrip¬ 
tion.  These  perspectives  are  invaluable  for  tools  that  require 
knowledge  of  the  system  structure,  such  as  fault  diagnosis  and  test  gen¬ 
eration  tools  [13]-  There  appears  to  be  a  trend  toward  hierarchical 
representations  of  systems  for  computer-aided  design  (CAD)  tools  because 
using  hierarchy  is  a  natural  technique  for  reducing  the  apparent  com¬ 
plexity  of  a  system  by  providing  abstractions  of  each  level  of  the  sys¬ 
tem  [5,14,15].  In  order  to  fully  utilize  the  power  of  hierarchical 
representation  the  tools  must  use  the  hierarchy  internally,  rather  than 
flattening  a  hierarchical  description,  and  perform  all  reporting  to  the 
user  in  terms  of  the  hierarchy.  For  these  compelling  reasons  we  believe 
it  is  important  to  orient  our  work  towards  hierarchical  representations. 

The  goals  of  this  research  were  to  develop  an  alternative  fault 
simulation  technique  that  was  based  on  hierarchical  system  evaluation. 
We  also  wanted  our  technique  to  incorporate  the  advantageous  features  of 
both  concurrent  and  deductive  simulation,  but  without  many  of  the  disad¬ 
vantages.  The  hybrid  technique  which  is  detailed  in  Chapter  3  is 
inherently  hierarchical  and  uses  an  unordered  list-based  propagation 
technique.  This  avoids  the  ordered  list  operations  and  deduction  equa¬ 
tions  of  the  deductive  technique  and  also  avoids  (when  possible)  the 
replication  of  machines  which  penalizes  the  concurrent  technique. 


j 


-  * 


4 


Most  fault  simulators  are  tied  to  a  particular  technology  through 
the  fault  model  embedded  in  the  simulator.  Changing  the  fault  model 
usually  requires  modifying  the  simulator,  a  task  few  users  want  to  per¬ 
form.  Our  final  goal  then  was  to  increase  the  usefulness  of  our  fault 
simulation  technique  by  decoupling  the  fault  model  from  the  simulator, 
so  that  a  change  in  fault  models  requires  changing  data  files,  not  modi¬ 


fying  programs. 


2.  COMPARISON  OP  FAULT  SIMULATION  TECHNIQUES 


An  informal  comparison  of  simulation  techniques  quickly  shows  why 
concurrent  simulation  is  more  efficient  than  parallel  simulation.  It 
also  shows  why  parallel  simulation  performs  better  for  smaller  circuits, 
and  concurrent  simulation  for  larger  circuits.  For  any  type  of  fault 
simulator,  each  fault  must  be  examined  and  its  consequences  applied  to 
the  circuit.  Since  the  circuit  is  represented  as  a  collection  of  simu¬ 
lator  primitives,  the  effect  of  these  faults  must  be  determined  from 
evaluating  the  primitives,  and  similarly  the  effect  of  the  faults  on 
other  parts  of  the  system  must  be  determined  by  applying  the  result  of 
the  faults  to  these  other  elements  to  determine  their  response. 

If  the  various  simulation  techniques  can  be  modelled  by  equations 
derived  from  characteristics  of  the  simulation  algorithms,  then  these 
equations  can  be  used  to  predict  simulator  performance.  In  this  chapter 
simple  performance  models  of  parallel,  deductive,  and  concurrent  fault 
simulation  are  derived  from  their  algorithms.  These  models  are  used  to 
help  explain  the  performance  characteristics  of  the  various  techniques. 
Finally,  the  models  are  used  to  hypothesize  approaches  to  improving 
fault  simulator  performance.  To  simplify  the  models,  we  neglect  any 
one-time  overhead  such  as  initialization  or  output  which  is  relatively 
independent  of  the  circuit  size  or  composition  and  assume  measured  aver¬ 
ages  for  terms  that  vary  with  circuit  topology  or  input  stimulus.  The 


cost  factor  derived  here  is  called  the  primitive  fault  product  or  PFP 
and  is  a  function  of  the  following  parameters: 


F  =  total  number  of  possible  faults  for  the  circuit 
f  =  average  number  of  faults  for  each  primitive  (parallel) 

f*  =  average  number  of  faults  for  each  primitive  (deductive) 

f"  =  average  number  of  faults  for  each  primitive  (concurrent) 

w  =  word  width  of  the  target  computer 

b  =  number  of  bits  used  to  represent  a  logical  value 
P  =  number  of  circuit  elements  (simulator  primitives) 

K  =  (w/b)  -  1  (faulty  machines  evaluated  in  parallel) 
a  =  activity  factor  in  event-driven  simulation  (0<a<<1) 
b  =  fault  collapsing  factor  (0<b<1) 
c  =  cost  per  evaluation  (cpu  seconds) 


Since  changes  in  input  may  not  affect  many  of  the  signals  within  a  sys¬ 
tem  being  simulated!  event-driven  simulation  improves  performance  by 
evaluating  only  the  signals  that  change  (the  activity).  Typically,  this 
activity  affects  only  5-20J  of  the  system,  so  80J  or  more  of  the  evalua¬ 
tion  performed  by  a  compiled  simulator  is  avoided.  The  activity  factor 
a  eccounts  for  this  improvement.  The  fault  collapsing  factor  b  accounts 
for  the  reduction  in  the  number  of  faults  the  simulator  deals  with  due 
to  fault  folding,  fault  collapsing,  and  fault  dominance.  Evaluations 
for  the  cost  factor  c  are  the  number  of  then  most  meaningful  simulator 
events  for  each  technique.  For  parallel  simulation,  an  evaluation  is 
the  processing  of  one  primitive  for  a  group  of  machines.  In  deductive 
and  concurrent  simulation,  an  evaluation  is  the  processing  of  one  fault 
or  list  of  equivalent  faults. 


2.1.  Parallel  Fault  Simulation 

In  parallel  fault  simulation,  word  instructions  are  used  to  evalu¬ 
ate  the  same  device  in  several  different  faulty  machines  at  the  same 
time.  The  virtual  data  structure,  shown  in  Figure  1 ,  demonstrates  how 
this  is  accomplished.  The  columns  represent  the  nodes  of  the  circuit 
and  the  rows  represent  the  different  faulty  machines.  Row  0  represents 
the  fault- free  circuit.  Because  the  nodes  are  aligned  with  the  words, 
and  the  faulty  machines  across  the  words,  a  computer  instruction,  per¬ 
forming  a  logical  operation  on  two  words,  simultaneously  performs  the 
evaluation  of  that  operation  on  the  same  nodes  for  several  different 
machines.  This  parallelism  significantly  speeds  up  the  fault  simula¬ 
tion.  The  speedup  factor  depends  on  how  many  machines  can  be  packed 
into  one  word.  A  more  detailed  explanation  of  the  parallel  fault  simu- 
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Figure  1.  Virtual  Data  Structure  for  Parallel  Simulation 


lation  algorithm  can  be  found  in  [8]. 

The  virtual  data  structure  previously  described  can  also  be  used  to 
develop  a  measure  of  the  computation  performed  during  a  fault  simula¬ 
tion.  The  evaluation  of  all  faulty  machines  requires  either  F/K  or 
F/K+1  passes.  Since  each  primitive  must  be  evaluated  at  least  once  per 
pass,  in  a  compiled  simulation  (more  if  the  circuit  contains  feedback 
loops),  the  total  number  of  evaluations  performed  is  P#(F/K).  Substi¬ 
tuting  fP  for  F  shows  the  second  order  nature  of  the  parallel  fault 
simulation.  There  are  several  techniques  for  increasing  the  speed  of 
parallel  simulation,  such  as  fault  folding  and  activity  directed 
(event-driven)  simulation,  but  none  of  these  techniques  changes  the 
order  of  the  algorithm.  The  expanded  form  of  this  equation  then  is 

PFP  =  abcP( fP)/( (w/b)-1 ) 

2.2.  Deductive  Fault  Simulation 

Deductive  fault  simulation,  developed  by  Armstrong  [9]  simulates 
only  the  good  machine  and  computes  the  effect  of  the  faults  with  fault 
list  equations.  These  equations,  defined  here  as  deduction  equations, 
perform  the  operations  of  set  intersection,  union,  and  complement  on 
fault  lists  and  the  super  fault  list.  The  super  fault  list  is  the  list 
of  all  possible  faults  and  the  complement  of  a  fault  list  is  defined  as 
all  faults  not  present  in  the  list,  or  the  super  fault  list  minus  the 
list  to  be  complemented.  The  set  intersection  and  union  computations 
become  slow  when  they  involve  large  sets  because  these  operations 


perform  insertions  and  deletions  on  ordered  sets.  The  complement  opera¬ 
tion  is  especially  costly  because  it  involves  copying  (with  deletions) 
the  super  fault  list. 

The  deduction  equations  are  data  dependent  and  must  be  derived  dur¬ 
ing  simulation.  For  a  gate  with  all  inputs  at  non-controlling  values  (0 
for  an  OR  and  1  for  an  AND)  the  deduction  equation  is  derived  by  the 
formula:  The  output  list  is  the  union  of  all  the  input  lists  and  the 
output  stuck  at  the  controlling  value. 

joutputi  {union  of  )  {  output  stuck 

)  list  f  =  'all  input!  u  /at  controlling 

(  lists  )  {  value 

If  some  of  the  inputs  are  at  controlling  values  ( 1  for  an  OR  and  0  for 

an  AND)  then  the  equation  becomes  more  complicated.  The  output  list  is 

the  output  stuck  at  the  non-controlling  value  and  the  intersection  of 

the  complement  of  the  union  of  non-controlling  input  lists  and  the  union 

of  controlling  input  lists. 

joutputJ  {output  stuck  at)  (  union  of  )  {  union  of  f 

{  list  /  =  /non-controlling!  ij  (non-controlling!  n  (controlling! 

{  value  )  U  input  lists  )  (input  lists)_ 

More  details  of  this  technique  can  be  found  in  Baker  [10].  The  deduc¬ 
tive  technique  is  not  as  versatile  as  other  fault  simulation  techniques 
because  of  its  list-based  algorithm,  but  recent  and  advances  in  string 
processors  may  dramatically  change  this  situation  very  soon  [163.  More 
recent  work  has  generalized  the  deductive  simulation  technique  [17].  A 
comparison  of  several  fault  simulation  techniques  is  presented  in  Leven- 
del  [18]  which  is  particularly  interesting  because  it  considers  extended 


versions  of  each  technique. 

In  deductive  simulation  the  number  of  faults  evaluated  at  each 
primitive  is  the  sum  of  the  number  of  faults  present  at  the  inputs  of 
the  primitive,  the  output  fault,  and  the  total  number  of  faults  F  if  any 
lists  are  complemented.  The  number  of  faults  present  on  the  inputs  is 
much  less  than  the  total  number  of  faults  so  the  frequency  of  list  com¬ 
plement  operations  strongly  influences  the  average  number  of  faults  pro¬ 
cessed  at  each  primitive  f ' .  The  cost  for  performing  each  pass  of  a 
deductive  simulation  is: 

PFP  =  abcPf * 

2.3.  Concurrent  Fault  Simulation 

The  concurrent  fault  simulation  algorithm  was  developed  by  Ulrich 
and  Baker  [10]  and  is  characterized  by  scheduling  the  good  machine  and 
all  faulty  machines  in  the  same  event  queue.  More  recent  work  has  been 
reported  which  emphasizes  improving  the  performance  aspects  of  con¬ 
current  simulation  [19].  In  this  technique  simulation  begins  by  apply¬ 
ing  a  vector  to  the  primary  inputs  and  evaluating  the  first  available 
primitive  for  the  good  machine.  As  each  primitive  is  evaluated,  the 
faults  in  that  primitive  that  are  activated  by  the  current  stimulus 
spawn  new  machines.  These  machines  differ  from  the  good  machine  by  the 
effect  of  the  fault.  There  is  no  difference  in  the  processing  of  the 
faulty  machines  and  the  good  machine  except  that  only  the  good  machine 
triggers  the  spawning  of  new  machines.  Spawning  more  faulty  machines 
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from  faulty  machines  would  effect  a  multiple  fault  evaluation.  As  each 
faulty  machine  is  spawned,  the  current  state  of  the  good  machine  is 
duplicated,  and  the  new  machine  is  added  to  the  evaluation  queue. 
Clearly,  duplicating  the  entire  state  of  the  good  machine  for  each 
faulty  machine  produces  maximum  flexibility,  but  is  very  expensive  in 
terms  of  memory  space. 

Concurrent  fault  simulation  is  inherently  an  event-driven  algo¬ 
rithm.  Therefore  the  PFP  is  dependent  on  the  input  stimulus,  which 
determines  what  faults  are  activated,  propagated,  or  absorbed.  The 
total  number  of  evaluations  is  the  summation  over  the  primitives,  of  all 
the  faults  propagated  to  each  primitive,  plus  all  the  faults  activated 
in  that  primitive,  plus  the  good  machine  evaluation.  This  metric, 
because  of  its  sensitivity  to  the  input,  is  difficult. to  use,  instead, 
use  the  average  number  of  faults  evaluated  per  primitive  f",  a  measur¬ 
able  quantity.  Since  f"  is  generally  large,  any  technique  which 
decreases  the  average  number  of  faults  evaluated  per  primitive  will  sig¬ 
nificantly  improve  the  performance  of  the  simulator.  A  dynamic  fault 
collapsing  technique,  detailed  in  Chapter  3,  decreases  this  average  to 
the  minimum  possible  value. 

The  PFP  then  is  the  sum  of  good  machine  evaluations  P,  faulty 
machine  evaluations  Pf",  and  the  appropriate  constants  for  activity  and 
cost: 


PFP  =  acP(f%1) 


This  equation  appears  linear,  but  f"  is  dependent  on  the  number  of 
primitives,  the  input,  and  circuit  topology. 

2.4.  Characteristics  of  the  Simulation  Models 

Although  these  models  are  quite  simple  they  highlight  the  salient 
parameters  that  affect  simulator  performance.  The  models  show  that  the 
performance  of  all  the  techniques  is  a  function  of  the  product  of  primi¬ 
tives  and  faults,  which  implies  that  performance  can  be  improved  by 
reducing  this  product.  The  number  of  faults  can  be  reduced  by  parti¬ 
tioning  the  fault  set  or  static  fault  collapsing,  and  the  number  of 
primitives  can  be  reduced  by  redefining  the  system  in  terms  of  more 
comprehensive  primitives.  There  is  a  caveat  in  the  last  approach 
because  more  complex  primitives  encompass  more  faults  so  the  average 
number  of  faults  per  primitive  increases  with  primitive  complexity  and 
the  primitive-fault  product  may  not  change  very  much.  However,  fault 
reduction  techniques  are  more  successful  with  the  more  complicated 
"primitives",  so  the  total  number  of  faults  and  therefore  the 
primitive- fault  product  can  be  reduced. 

2.5.  Concurrent  Versus  Deductive  Simulation 

The  cost  factor  for  parallel  simulation  is  much  smaller  than  the 
cost  per  evaluation  in  concurrent  simulation  because  the  parallel 
evaluation  is  much  less  complicated,  involves  less  overhead  manipulating 
data  structures,  and  is  amortized  over  several  different  machines.  For 
small  numbers  of  faults  and  primitives,  parallel  simulation  is  faster, 
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but  for  large  numbers  of  faults  and  primitives  concurrent  simulation  is 
faster.  The  crossover  point  seems  to  be  around  1000  simulator  primi¬ 
tives  [11]. 

In  this  section  the  two  most  viable  techniques  for  fault  simulation 
are  compared  in  sufficient  detail  to  show  the  advantages  and  disadvan¬ 
tages  of  each.  The  discussion  is  intended  to  motivate  the  development 
of  a  hybrid  algorithm  which  incorporates  the  advantages  of  both  con¬ 
current  and  deductive  simulation. 

The  main  disadvantages  of  deductive  fault  simulation  are  that  it 
requires  storage  of  long,  ordered  fault  lists  at  each  node,  and  the  pro¬ 
cessing  of  these  ordered  lists  is  expensive,  particularly  the  complement 
operation.  Since  the  complement  operation  occurs  very  -frequently,  it 
severely  degrades  simulator  performance.  This  technique  also  suffers  a 
large  memory  penalty  because  the  super  fault  list,  which  is  frequently 
scanned,  must  be  explicitly  stored  in  memory.  Since  only  the  good 
machine  is  evaluated,  and  the  faulty  machines  are  deduced,  all  the 
faulty  machines  implicitly  have  the  same  timing  characteristics  as  the 
good  machine,  so  representation  of  timing  faults  is  very  cumbersome. 
One  final  difficulty  with  deductive  simulation  is  that  the  deduction 
equations  are  data  dependent  and  must  be  derived  for  each  stimulus.  The 
derivation  of  these  equations  is  simple  for  traditional  gates,  but 
becomes  much  more  complicated  (and  time  consuming)  for  more  complex 
modules.  Expansion  of  the  fault  algebra  aggravates  all  of  these  prob¬ 


lems. 


16 

In  comparison,  the  disadvantages  of  concurrent  simulation  are  that 
it  copies  the  entire  machine  state  each  time  a  new  fault  is  activated. 
Copying  the  entire  machine  state  is  expensive  in  terms  of  both  memory 
and  time.  Since  the  different  machines  are  completely  independent,  con¬ 
current  simulation  can  represent  timing  faults  as  easily  as  level  or 


logical  faults. 
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3.  HIERARCHICAL  FAULT  SIMULATION  SYSTBf 


The  simulation  system  developed  to  achieve  the  research  goals,  con¬ 
sists  of  three  major  parts:  two  preprocessors  for  the  fault  library  and 
circuit  source,  and  an  evaluator  which  performs  the  fault  simulation. 
The  preprocessors,  constructed  with  LEX  [20]  ,  a  program  for  generating 
lexical  analyzers,  and  YACC  [21]  ,  a  program  for  generating  parsers, 
parse  their  respective  source  files  and  produce  data  structures  for  the 
evaluator.  The  internal  data  structures  are  constructed  as  the  source 
file  is  read  and  the  result  is  a  compact,  linked  list  data  structure 
(directed  acyclic  graph),  with  links  along  all  the  paths  the  simulator, 
is  expected  to  need.  The  resulting  data  structure  is  then  transformed 
into  a  relocatable  structure  by  making  all  pointers  relative  to  the  base 
of  the  data  structure.  This  structure  is  then  written  to  a  file  for 
later  use  by  the  evaluator. 

The  data  structures  were  parsed  in  separate  programs  for  several 
reasons.  First,  under  UNIX*,  it  is  difficult  to  call  two  YACC-generated 
parsers  from  the  same  program  because  YACC  gives  all  parsers  the  same 
name.  One  of  the  parsers  could  be  renamed  by  editing  the  YACC  output 
file,  but  this  approach  adds  another  step  in  the  edit-compile-test  cycle 
and  is  undesirable  from  a  maintainability  standpoint.  Second,  there  is 
no  need  to  reprocess  both  the  circuit  and  the  fault  library  if  only  one 
e 
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of  the  two  has  changed.  For  small  circuits  or  fault  libraries,  this 
extra  overhead  is  negligible,  but  for  larger  systems  the  overhead  may  be 
significant.  Third,  for  stylistic  and  maintenance  purposes,  it  is  much 
easier  to  cope  with  three  specialized  programs  than  with  one  large 
conglomeration.  In  the  following  sections  each  part  of  the  simulator  is 
discussed  in  detail. 

3.1.  Fault  Library 

This  section  focuses  on  the  fault  library  segment  of  the  simulator. 
The  intent  is  to  separate  the  core  evaluation  routines  o.  the  simulator 
from  the  details  of  the  fault  model.  This  separation  allows  the  simula¬ 
tor  to  be  used  for  different  technologies  without  modification,  and 
allows  easy  expansion  of  the  simulator  primitive  set.  An  algorithm  for 
combining  primitives  to  form  new  primitives  has  been  developed  which 
will  be  presented  in  future  research. 

The  fault  library  represents  the  precomputation  and  orderly  storage 
of  fault  syndromes  for  all  primitive  elements.  These  syndromes  may  be 
computed  for  any  fault  with  a  logically  modelled  effect  at  the  output  of 
the  primitive.  This  means  either  the  wrong  logical  value,  or  the 
correct  value  at  the  wrong  time.  This  allows  a  more  comprehensive  fault 
model  than  the  traditional  stuck-at  fault  model  which  has  been  proven 
inadequate  [22,23,24].  Precomputation  of  the  fault  syndromes  decouples 
the  simulator  from  the  fault  model  in  the  sense  that  the  fault  model  is 
embedded  in  the  primitive  library  instead  of  in  the  simulator  evaluation 
routines.  Thus  different  technologies  with  different  fault  models  can 


be  incorporated  in  the  simulation  system  by  building  a  primitive  library 
of  fault  syndromes  which  correspond  to  that  technology.  This  method  is, 
of  course,  sensitive  to  the  completeness  of  the  fault  library  entries 
for  the  primitives. 

The  preprocessor  for  the  fault  library  parses  the  source  for  the 
fault  library  and  produces  a  relocatable  linked  list  data  structure  for 
the  evaluator.  The  input  is  structured  in  a  simple  LR(0)  grammar  con¬ 
sisting  of  about  eight  keywords,  four  separators,  alphanumeric  symbols, 
and  four-valued  signal  vectors.  The  case  of  alphabetic  characters  is 
significant,  and  the  parser  ignores  blanks,  tabs,  new  lines,  and  "  /• 
comments  */".  A  sample  entry  for  a  three  input  AND  gate  is  shown  in 
Figure  2.  Each  entry  in  the  fault  library  begins  with  the  keyword  PRIM¬ 
ITIVE,  followed  by  an  equal  sign,  then  the  name  of  the  primitive.  This 
name  is  followed  by  INPUT,  OUTPUT,  and  FAULTLIST  sections.  The  input 


PRIMITIVE=AND3 
INPUT  3  :  1=A,2=B,3=C 
OUTPUT  4  :  4=FAND 


FAULTLIST  7  : 
A1.FAND1  01 1 > 

B1 , FAND1  101 > 

C1.FAND1  1 10> 

AO ,B0 , CO, FANDO  1 1 1 < 
FAND1  0??> 

FAND1  ?0?> 

FAND1  ??0> 


Figure  2.  Fault  Library  Source  for  a  3  Input  AND  Gate 
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and  output  sections  have  similar  structure,  the  keyword  INPUT  or  OUTPUT 
followed  by  a  number,  then  a  list  of  signal  names  and  their  correspond¬ 
ing  positions  in  the  I/O  vector.  These  assignments  have  the  form  "sig¬ 
nal  number  =  signal  name",  and  are  separated  by  commas.  The  number  fol¬ 
lowing  the  keyword  is  the  number  of  signals  in  the  following  list  and  is 
used  by  the  parser  to  allocate  storage  in  advance  for  the  signal  list. 
The  keyword  FAULTLIST  (if  present)  is  followed  by  the  number  of  vectors 
following  the  keyword  for  the  same  purpose. 

The  vectors  following  the  keyword  FAULTLIST  are  composed  of  tuples, 
a  list  of  faults  covered  by  the  vector  and  a  signal  vector  composed  of 
logic  values.  In  the  current  implementation  there  are  five  logic 
values : 

1  logic  one 
0  logic  zero 

>  error,  should  be  zero  but  is  one  under  fault 
<  error,  should  be  one  but  is  zero  under  fault 
?  don’t  care 
%  unknown 

The  exact  representation  of  the  logic  values  is  immaterial;  these  sym¬ 
bols  were  chosen  for  ease  of  parsing,  and  they  are  intended  for  internal 
use  only.  The  list  of  faults  included  in  the  tuple  has  no  meaning  to 
the  evaluator.  It  is  completely  up  to  the  user  to  establish  any  desired 
fault  naming  convention.  The  set  of  faults  which  can  produce  an  error 
on  a  particular  line  for  the  current  input  is  indistinguishable  [25,26], 
30  the  evaluator  does  not  care  whether  the  fault  name  list  associated 
with  a  vector  represents  one  or  many  faults.  The  simulator  treats  each 


list  of  fault  names  uniquely  even  if  there  exist  other  strings  with  the 
same  lexical  value  (sequence  of  symbols).  This  uniqueness  is  required 
since  two  faults  may  have  identical  names;  the  uniqueness  is  established 
by  their  location  in  the  circuit  hierarchy.  In  fact,  the  contents  of 
these  name  lists  are  never  examined  by  the  simulator. 

3.2.  Scald  Circuit  Description 

The  circuit  definition  language  is  a  subset  of  the  Structured 
Computer-Aided  Logic  Design  language  (SCALD)  [27].  This  language  was 
chosen  because  it  is  a  hierarchical  circuit  description  language  and 
previous  work  at  the  University  of  Illinois  implemented  SCALD  output 
from  the  graphics  editor  DRAW  [28].  In  SCALD,  the  circuit  is  hierarchi¬ 
cally  defined  in  terms  of  macromodules  which  are  defined  in  terms  of 
other  macromodules  and/or  simulator  primitives.  Macromodules  and  primi¬ 
tives  may  have  multiple  inputs  and  outputs.  Figure  3  shows  the  SCALD 
definition  of  an  Exclusive  Or. 

MNAMEsXOR; 

PARAMETERS  a , b , c ; 

INV( L0C=X0R1 ) (A=a, FINVrNULf 00001 ) ; 

INV( L0C=X0R2 ) ( A=b , FINVsNUL? 00002 ) ; 

NAND2(LOC=XOR3) (A=a,B=NULf 00002, FNAND=NUL$00003) ; 

NAND2( L0C=X0R4 ) ( A=b , B=NULX00001 , FNAND=NUL$  00004 ) ; 

NAND2( L0C=X0R5 ) ( A=NUL* 00003 , B=NUL*00004 , FNAND=c) ; 

END; 

Figure  3.  SCALD  Definition  of  an  Exclusive  Or  Module 
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The  module  name  follows  the  keyword  MNAME  and  is  terminated  with  a 
semicolon.  The  next  line  beginning  with  the  keyword  PARAMETER 
enumerates  the  input-output  lines;  order  is  unimportant.  Most  simula¬ 
tors  are  based  on  gate  level  primitives  with  only  one  output,  this  is 
not  adequate  since  many  technologies  permit  structures  which  have  no 
gate  equivalent.  The  multiple  input/multiple  output  capability  of  SCALD 
is  much  more  powerful  in  this  respect.  The  parameters  (signals)  are 
followed  by  calls  to  other  modules,  either  macromodules  or  primitives. 
These  calls  consist  of  the  module  name  followed  by  a  unique  location  and 
then  the  list  of  signal  bindings.  The  location  distinguishes  between 
several  calls  to  the  same  module  and  the  signal  bindings  provide 
correspondences  between  the  signal  names  in  the  called  module  and  the 
signal  names  in  the  calling  module.  The  module  calls  are  followed  by 
the  keyword  END  to  signify  the  end  of  the  current  module  definition. 

This  hierarchical  description  is  compact  because  each  module  is 
defined  only  once  but  can  be  called  many  times.  This  representation  is 
much  more  compact  than  expanding  the  circuit  to  the  lowest  level  ( simu¬ 
lator  primitives).  This  compactness  provides  better  locality,  which  is 
important  for  good  cache  miss  and  page  fault  ratios,  since  the  circuit 
description  is  constantly  scanned  by  the  evaluator. 

3.3.  The  Evaluator 

The  evaluator  is  the  core  of  the  fault  simulation  system.  This 
program  reads  the  data  structures  produced  by  the  two  preprocessors  and 
relocates  each  according  to  its  base  address.  Then  some  additional 


linking  is  performed  to  link  SCALD  calls  to  primitives  to  the  appropri¬ 
ate  fault  library  definition  of  those  primitives,  and  to  link  the  primi¬ 
tives  to  a  functional  evaluation  routines.  Once  this  process  is  com¬ 
plete,  the  evaluator  is  ready  to  apply  vectors  to  the  circuit. 

The  evaluation  begins  by  applying  the  input  vector  to  the  highest 
level  scald  module,  which  must  encompass  the  entire  circuit.  The 
evaluator  reorders  the  vector  and  proceeds  to  call  itself  recursively 
through  macromodule  calls  until  a  simulator  primitive  is  encountered. 
The  result  of  this  evaluation  is  then  applied  to  the  next  higher  module 
and  another  call  at  that  level  is  given  to  the  evaluator.  This  process 
continues  until  all  the  pending  activity  at  the  current  level  is  com¬ 
pleted,  then  the  evaluator  returns  the  result  to  the  next  higher  level. 
This  process  implements  a  depth-first  evaluation  of  the  circuit. 

The  evaluation  process  consists  of  two  major  portions,  macromodule 
evaluation  and  primitive  evaluation.  The  macromodule  evaluation  occurs 
first  and  is  the  simplest  so  it  will  be  discussed  first. 

3.4.  Macromodule  Evaluation 

Macromodule  evaluation  consists  of  two  parts,  choosing  the  next 
available  module  call  to  evaluate  and  reordering  the  signal  vector  for 
that  call.  If  a  scheduling  algorithm  is  used,  the  order  of  evaluation 
may  not  correspond  to  the  static  ordering  in  the  module  definition, 
since  some  signals  may  be  undefined  (internal  nodes),  and  some  modules 
may  be  evaluated  more  than  once  in  sequential  circuits.  When  all  the 
modules  have  been  evaluated  and  there  is  no  more  internal  signal 
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activity*  the  macromodule  evaluation  process  terminates  by  returning  to 
the  calling  level,  with  updated  external  signal  values.  These  values 
may  be  scheduled  for  application  to  the  circuit  at  some  time  in  the 
future. 

3.5.  Primitive  Evaluation 

Primitive  evaluation  is  somewhat  more  complicated,  but  also  a  two 
step  process,  fault  activation  in  the  current  module  and  error  propaga¬ 
tion  from  the  inputs  to  the  outputs  of  the  current  module. 

3.5.1.  Fault  Injection 

The  fault  injection  process  is  characterized  by  table  lookup  for 
matches  in  the  fault  library  with  the  current  input  vector.  These 
matches  are  calculated  with  a  matching  function  that  resolves  disparate 
values  for  the  same  signal  into  matches  or  differences.  This  function 
is  responsible  for  matching  with  don’t  cares  and  unknowns.  If  one  or 
more  vectors  are  matched  from  the  fault  library,  the  corresponding  fault 
lists  are  attached,  along  with  the  complete  path  to  the  current  module, 
to  all  outputs  which  evidence  the  errors.  A  fault  (list)  may  appear  on 
more  than  one  output,  which  complicates  the  task  of  fault  propagation. 

3.5.2.  Fault  Propagation 

Once  fault  activation  is  complete,  the  input  signals  are  scanned 
for  attached  fault  lists.  If  the  signals  contain  fault  lists,  these 
lists  are  decomposed  into  sets  characterized  by  unique  error  syndromes 
at  the  inputs  of  the  current  module.  The  decomposition  is  done  with  a 


double  hashing  process:  first,  the  error  is  hashed  according  to  its  name 
and  location,  then  according  to  the  input (s)  on  which  it  occurs.  The 
result  of  this  hashing  is  an  inverted  list  where  all  of  the  fault  lists 
with  the  same  error  syndrome  are  collapsed  into  a  single  fault  list. 
Each  of  the  unique  error  syndromes  is  then  evaluated  with  the  functional 
model  of  the  primitive  and  the  results  compared  to  the  good  module  out¬ 
puts.  If  the  outputs  differ,  then  the  errors  creating  the  current  syn¬ 
drome  propagate  on  all  outputs  which  differ  from  the  good  machine.  Pro¬ 
pagation  is  effected  by  attaching  the  list  of  fault  lists  to  the 
appropriate  outputs.  If  the  syndrome  creates  an  output  which  is  identi¬ 
cal  to  the  good  machine,  then  the  errors  are  marked  as  potentially 
absorbed  (they  may  be  propagated  elsewhere)  for  later  processing.  Each 
syndrome  Is  evaluated  in  turn  until  all  syndromes  are  exhausted.  In  the 
worst  case,  the  number  of  syndromes  is  equal  to  the  input  range  of  the 
module,  but  in  practice  it  should  be  only  a  small  fraction.  The  most 
significant  feature  of  this  process  is  that  the  maximum  possible  col¬ 
lapsing  is  performed  on  error  syndromes  because  they  are  dynamically 
collapsed. 


4.  FAULT  SIMULATION  EXAMPLES 


In  this  chapter  the  fault  simulation  algorithm  is  further  clarified 
through  examples.  The  first  example,  an  Exclusive  Or  circuit,  demon¬ 
strates  the  details  of  the  algorithm.  The  second  example,  a  fast  multi¬ 
plier,  shows  how  the  simulator  behaves  with  realistic  circuits  and  indi¬ 
cates  how  well  the  simulator  performs. 

4.1.1.  Exclusive  Or 

In  this  section  an  example  of  the  simulation  algorithm  is  presented 
using  an  Exclusive  Or  circuit.  This  circuit,  shown  in  Figure  4,  is  a 
multiple  input,  single  output  module,  composed  of  gate-level  primitives. 
Although  using  a  gate-level  description  does  not  fully  utilize  the  capa¬ 
bilities  of  the  simulator,  it  is  easy  to  follow. 


The  notation  used  in  this  example  is  simple,  the  gates  are  referred 
to  by  location,  i.e.,  X0R1 ,  and  the  circuit  nodes  are  labelled,  i.e.,  T. 
Fault  names  are  not  required  to  be  unique,  and  as  seen  in  this  example, 
a  unique  location  is  required  to  fully  qualify  fault  names.  Lists  of 
indistinguishable  faults  are  enclosed  in  parentheses  with  the  unique 
location  beginning  the  list,  and  lists  of  these  fault  lists  are  enclosed 
in  square  brackets  to  denote  a  fault  list.  The  simulator  does  not  store 
the  lists  or  manipulate  the  data  in  exactly  this  form;  the  notation  is 
intended  for  clarity.  Some  details  of  the  simulation  have  been  left 
out,  but  this  example  illustrates  the  essence  of  the  simulation  algo¬ 
rithm. 

Let  the  input  vector  take  the  value  10  on  inputs  QR.  The  scheduler 
determines  that  only  modules  (in  this  case  primitives)  XOR1  and  X0R2 
have  completely  known  inputs;  all  other  modules  have  some  unknown 
inputs.  The  scheduler  chooses  to  evaluate  module  X0R1  first  because  it 
is  the  first  module  in  the  list  of  evaluable  modules.  Evaluating  X0R1 
for  the  input  Q=1  determines  that  the  output  SsO;  this  constitutes  the 
good  machine  evaluation.  Next  the  fault  library  entry  for  this  type  of 
module  (inverter)  is  searched  for  matches  with  the  input  vector.  This 
is  the  activation  phase  of  fault  simulation.  One  match  is  found  and 
this  match  is  attached  to  the  output  vector  for  module  X0R1 .  This 
attachment  is  denoted  by  the  signal  name  and  value  followed  by  the  list 
of  fault  names: 

S=0  [ ( X0R1 , AO , FINV 1 ) ] 

There  are  no  faults  attached  to  the  input  so  the  fault  propagation  phase 
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is  skipped.  The  evaluation  is  completed  by  scheduling  the  change  in  S 
to  occur  at  the  appropriate  time  in  the  future.  There  is  only  one 
module  X0R2  left  on  the  evaluation  list,  so  XCR2  is  evaluated  next.  The 
input  R=0  produces  the  output  T=1  and  the  fault  library  search  yields 
one  match, 

T=1  [ (X0R2.A1 ,FINV0) ] 

Again  there  are  no  faults  attached  to  the  input  so  the  fault  propagation 
phase  is  skipped,  and  the  output  T  is  scheduled  to  change  at  the 
appropriate  time  in  the  future.  In  this  example  the  changes  in  S  and  T 
are  assumed  to  occur  at  the  same  time. 

Since  the  evaluation  list  is  empty,  the  simulator  clock  advances  to 
the  next  signal  event,  where  the  changes  in  S  and  T  are  applied.  The 
scheduler  checks  all  modules  affected  by  these  changes  and  finds  that 
modules  X0R3  and  X0R4  may  now  be  evaluated.  The  good  machine  evaluation 
of  X0R3  determines  that  for  the  input  vector  QT=11,  the  output  U=0. 
Searching  the  fault  library  entry  for  a  2  input  NAND  produces  one 
match, 

U=0  C(X0R3,A0,B0,FNAND1)] 

The  input  Q  does  not  have  any  attached  faults,  but  the  input  T  does,  so 
these  faults  must  be  checked  for  propagation  through  the  module.  Since 
there  is  only  one  input  with  attached  faults,  no  fault  collapsing  is 
possible  so  this  step  is  skipped.  Next,  the  (only)  error  syndrome  is 
synthesized  QT'=10  and  applied  to  the  module,  which  determines  that 
U'sl.  Since  U'  and  U  differ  propagation  occurs,  and  the  fault  list 
associated  with  this  fault  syndrome  is  attached  to  the  output  U.  The 
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resulting  fault  list  attached  to  U  is  then 

U=0  [ (XOR3 , AO ,B0 , FNAND1 ) (X0R2 , A1 ,FINV0)] 

As  before  the  evaluation  ends  by  scheduling  the  output  change  at  the 
appropriate  tine  in  the  future. 

The  evaluation  of  X0R4  occurs  in  a  similar  fashion.  The  input  vec¬ 
tor  RS=00  produces  an  output  of  V=1,  and  there  is  one  match  in  the  fault 
library, 

V=1  [ (X0R4,FNAND0) ] 

Again,  only  one  input  contains  a  fault  list,  so  no  collapsing  is  done, 
and  the  one  error  syndrome,  RS'=01,  produces  an  output  V*=1.  Since  V  = 
V',  the  fault  list  associated  with  the  error  syndrome  i3  not  propagated, 
but  marked  as  "potentially"  absorbed.  Fanout  elsewhere  in  the  circuit 
could  have  allowed  other  paths  for  the  faults  to  propagate,  so  the  final 
determination  is  delayed  until  all  circuit  activity  has  ceased.  In  this 
case  it  is  easy  to  see  that  there  is  no  fanout  for  this  list  so  the 
fault  list  is  completely  absorbed. 

Again,  the  evaluation  queue  is  empty  so  the  simulation  clock  is 
advanced  to  the  next  signal  event  where  the  values  for  U  and  V  are 
changed.  These  signals  affect  X0R5  so  this  module  is  scheduled  for 
evaluation.  The  good  machine  evaluation  of  X0R5  for  the  input  vector 
UV=01  produces  the  output  W=1,  and  the  activation  phase  finds  one  match 
in  the  fault  library, 

W=1  [ (X0R5 , A1 , FNANDO) ] 

Both  inputs  U  and  V  have  attached  fault  lists  so  fault  collapsing  is 
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applied  to  the  input  vector.  The  fault  lists  are  disjoint  so  no  col¬ 
lapsing  occurs.  The  two  lists  of  faults  produce  two  error  syndromes, 

UV*=11  from  [ ( X0R3 , AO , BO , FNAND1 ) ]  attached  to  U 
UV"=00  from  [ (XORlJ ,FNAND0) ]  attached  to  V 

Since  tha  simulator  operates  under  the  single  fault  assumption,  there 
are  no  other  syndromes  possible.  Evaluation  of  the  first  syndrome 
UV*=11  produces  an  output  of  W’=0  which  differs  from  W,  so  the  associ¬ 
ated  fault  list  is  attached  to  W.  The  second  syndrome  UV"=00  produces 
an  output  of  W"=1  which  is  the  same  as  W  so  the  associated  fault  list 
does  not  propagate,  and  this  list  is  flagged  as  potentially  absorbed. 
The  final  fault  list  attached  to  W  is  then 

W= 1  [ ( X0R5 , A1 , FNANDO ) ( X0R3 , AO , BO , FNAND 1 ) ( X0R2 , A 1 , FINVO ) ] 

The  evaluation  of  X0R5  ends  by  scheduling  W  to  change  at  some  future 
time.  The  queue  is  again  empty  so  the  simulation  clock  advances  to  the 
only  remaining  event,  and  the  new  value  for  W  is  applied.  This  node  has 
no  fanout  to  any  other  modules  so  no  modules  are  scheduled  for  evalua¬ 
tion.  The  event  queue  and  the  evaluation  queue  are  now  empty  so  simula¬ 
tion  activity  is  ready  to  terminate. 

The  final  task  remaining  is  to  check  the  fault  list  attached  to  the 
primary  output  against  the  list  of  potentially  absorbed  faults  to  see 
which  faults  were  propagated  by  alternate  paths.  Faults  which  appear  in 
both  lists  are  removed  from  the  list  of  potentially  absorbed  faults 
since  they  are  proven  to  be  observable,  and  the  remaining  list  is 
reported  as  absorbed  faults.  In  this  example  the  list  of  absorbed 


faults  is 


This  information  about  absorbed  faults  is  useful  to  a  circuit  or  test 
designer  since  it  indicates  that  the  primary  input  was  sufficient  to 
activate  these  faults,  but  that  they  are  not  observable  because  propaga¬ 
tion  was  blocked  at  the  listed  locations. 

4.1.2.  Fast  Multiplier  Example 

The  following  example  is  a  24  bit  by  24  bit  fast  multiplier*  which 
produces  a  48  bit  result.  This  size  is  appropriate  for  mantissa  multi¬ 
plication  of  32  bit  floating  point  numbers.  This  design  trades  space 
for  speed  and  is  quite  large;  approximately  3  mm  by  3  mm,  and  represents 
about  30,000  active  devices.  For  simplicity  there  are  no  propagate, 
generate  carry  signals  or  carry  lookahead.  This  does  not  change  the 
functionality,  but  it  does  change  the  speed  of  the  multiplier.  The 
salient  features  of  the  design  which  produce  its  speed  are  that  a  number 
of  independent  partial  products  are  generated  in  parallel  and  then 
summed  in  parallel  via  several  stages  of  highly  vertical  adders,  with 
very  few  carries  between  adders. 

The  two  24  bit  inputs  are  divided  into  4  bit  nibbles,  and  each  com¬ 
bination  of  nibbles  is  used  to  generate  one  of  the  36  partial  products. 
These  partial  products  are  summed  in  three  stages  of  adders;  the  first 
two  stages  are  highly  vertical,  while  the  last  stage  is  more  horizontal. 

* 

Portions  of  this  example  were  provided  by  the  General  Electric  Cor¬ 
porate  Research  Center. 


The  vertical  adders  are  characterized  as  such  because  they  sum  a  colran 
of  five,  2  bit  wide  numbers.  The  horizontal  adders  sum  two,  4  bit  wide 


numbers.  One  of  the  horizontal  types  of  adders  also  accepts  a  carry 
input.  The  carries  which  normally  limit  the  speed  of  large  additions 
must  be  eventually  resolved.  This  resolution  occurs  in  the  last  stage 
and  requires  only  eight  carries  between  adder  modules.  The  cellular 
organization  of  the  multiplier  is  shown  in  Figure  5. 


The  SCALD  description  of  this  design  represents  five  levels  of 


hierarchy  with  21 ,000  interconnections  and  4500  instances  of  primitives. 


The  partial  SCALD  description  for  this  circuit  is  given  in  Appendix  A. 


The  first  level  consists  of  calls  to  the  four  types  of  macromodules  pre- 
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Figure  5.  Cellular  Organization  of  the  Fast  Multiplier 
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viously  described.  These  modules  consist  of  calls  to  other  macromo¬ 
dules,  which  eventually  lead  to  calls  to  the  simulator  primitives. 

The  4  by  4  bit  multiplier  used  to  generate  the  partial  products  is 
a  combinational  multiplier  similar  to  that  shown  in  Hayes  [29].  The 
multiplier  consists  of  two  major  parts;  an  AND  array  which  generates  2 
bit  partial  products  and  an  adder  array  to  sum  these  products.  See  Fig¬ 
ures  6  and  7  for  more  detail. 

The  partial  products  generated  by  these  multipliers  are  summed  in 
three  stages.  Each  stage  is  a  mixture  of  three  types  of  adders.  The 
first  type  is  a  vertical  adder  which  adds  five,  2  bit  wide  numbers.  The 
easiest  way  to  think  of  the  operation  of  this  adder  that  it  produces  the 
binary  weighted  sum  of  the  two  columns,  or  the  sum  of  the  right  column 


Figure  7.  Sum  Array  for  Fast  Multiplier  Example 


of  bits  summed  with  the  weighted  sum  (times  2)  of  the  left  column. 
While  not  the  largest  module,  the  design  for  this  module  is  the  most 
confusing.  This  design  is  shown  in  Figure  8.  The  final  two  modules 
consist  of  chains  of  full  and  half  adders.  Their  operation  is  obvious  as 


Figure  8.  55^  Adder  for  Fast  Multiplier  Example 
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Figure  9.  22235  Adder  for  Fast  Multiplier  Example 
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Figure  10.  22225  Adder  for  Fast  Multiplier  Example 

Using  the  system  profiler  [30]  the  simulator  was  found  to  spend 
most  of  its  time  in  fault  propagation  and  garbage  collection.  Although 
performance  of  the  simulator  depends  on  circuit  topology,  input  vector, 
and  number  of  faults  propagated,  approximate  performance  can  be  averaged 
over  a  wide  range  of  circuits,  for  many  input  vectors.  For  the  multi¬ 
plier  the  simulator  processed  the  4500  primitive  calls  (one  pass)  in  an 
average  of  45  seconds  per  input  vector  (60  seconds  with  profiling).  The 


size  of  the  simulation  in  memory  which  depends  on  these  same  attributes 
stablized  at  about  1.5M  bytes.  The  memory  allocation  breaks  down  as  88K 
bytes  for  the  simulator  code,  5 K  bytes  for  the  fault  library,  54k  bytes 
for  the  SCALD  description,  and  the  rest  is  workspace  for  fault  activity 
and  circuit  evaluation. 


5.  DISCDSSIOH  AID  COICLUSIOHS 


The  statistics  presented  in  Chapter  4  are  very  encouraging  for 
several  reasons.  First,  the  system  description  can  be  represented  in  a 
very  compact  form,  and  non-faulting  simulation  measurements  show  the 
overhead  for  walking  the  hierarchy  is  insignificant  compared  to  fault 
simulation.  Second,  the  fault  library  is  small  and  the  vector  lookup 
from  the  library  is  quite  fast.  The  library  can  be  kept  small  by  care¬ 
fully  choosing  its  contents.  The  execution  times  represent  1-2  orders 
of  magnitude  speed  improvement  over  the  TEGAS  fault  simulator  for  a 
similar  circuit.  Finally,  the  workspace  is  large  but  quite  acceptable 
for  a  large  circuit,  like  the  Fast  Multiplier  example,  especially  since 
no  minimization  techniques  such  as  data  packing  have  been  applied. 

Experience  with  the  simulation  system  has  shown  several  major 
advantages  to  this  approach.  The  compactness  of  the  hierarchical  cir¬ 
cuit  description  is  important  during  execution  because  it  significantly 
reduces  the  run-time  memory  requirements.  The  complete  design,  entry, 
and  debug  cycle  for  the  fast  multiplier  took  only  two  days.  The  design 
was  entered  in  a  top-down  fashion.  Functional  descriptions  were  pro¬ 
vided  for  each  type  of  module  and  the  highest  level  description  was 
debugged.  Then  each  of  the  modules  was  defined  in  more  detail,  and 
these  descriptions  were  debugged.  This  define-debug  cycle  continued 
until  complete  hierarchy  was  entered  and  debugged.  The  author  found 


that  the  hierarchical  data  structures  inside  the  simulator  aided  the 
development  of  user-friendly  reporting  for  debugging.  In  debugging  mode 
the  simulator  reports  the  position  in  the  hierarchy  by  dumping  the 
module  call  stack.  The  simulator  also  reports  the  I/O  vector  to  the 
current  module  by  printing  one  of  the  string  parameters  to  the  current 
evaluation.  This  contrasts  with  the  complicated  number- to- name  and 
table  lookup  often  required  to  do  similar  reporting  for  flat  system 
descriptions. 

The  simulation  system  as  presented  in  this  thesis  has  been  imple¬ 
mented.  This  implementation  was  sufficient  to  design  and  test  the  basic 
algorithm  and  with  enhancements  promises  to  become  a  complete  and  usable 
fault  simulator.  During  the  development  of  this  simulator  the  author 
found  that  there  were  a  few  disadvantages  to  simulating  from  a  purely 
hierarchical  data  structure.  Specifically,  there  is  some  information 
which  is  unique  to  each  instance  of  a  module  and  cannot  be  stored  in  the 
hierarchy.  For  instance,  state  information  is  necessary  for  each 
instance  of  a  sequential  module.  Since  the  hierarchy  is  unsuitable  for 
storing  state,  some  other  alternative  structure  must  be  used.  The 
author  chose  a  tree  data  structure  for  this  unique  information  because 
it  is  similar  to  the  hierarchy,  and  there  is  a  convenient  mapping  from 
one  structure  to  the  other.  In  this  scheme  the  simulator  can  walk  the 
hierarchy  to  access  invariant  information,  and  walk  the  tree  structure 
to  access  unique  information  for  each  module. 


While  state  information  is  the  most  obvious  use  of  the  tree,  it  is 
well  suited  to  logging  detected  faults  and  removing  them  from  further 
consideration.  Along  with  the  state  vector  for  each  module,  the  tree 
also  contains  a  fault  vector  with  one  entry  for  each  vector  in  the  fault 
library  for  that  type  of  module.  This  vector  can  be  used  to  mark  faults 
when  they  are  detected  at  the  primary  outputs,  and  remove  them  from 
further  consideration.  This  marking  substantially  improves  simulator 
performance  by  reducing  the  number  of  faults  under  consideration  in 
future  vectors,  which  increases  the  effective  execution  speed. 

This  marking  can  also  be  used  by  the  user  to  control  which  faults 
are  considered  by  the  simulation.  If  the  user  is  interested  in  the 
fault  coverage  of  a  particular  module  or  type  of  module  but  not  the  rest 
of  the  circuit,  then  by  marking  the  faults  in  these  modules  as 
undetected  and  all  others  as  detected,  the  simulator  will  inject  only 
these  faults.  The  user  can  then  develop  a  test  set  for  the  circuit 
module  by  module,  and  prevent  the  simulator  from  considering  faults  in 
modules  that  have  already  been  analyzed.  This  technique  is  a  manual 
form  of  partitioning  that  allows  the  user  to  maintain  the  full  capabil¬ 
ity  of  the  simulator  while  achieving  much  better  speed  by  controlling 
the  fault  injection. 


6 .  FUTURE  WORE 


i 

The  fault  simulation  techniques  presented  in  this  thesis  are  far 
from  complete.  The  preliminary  performance  results  indicate  that  these 
techniques  warrant  further  exploration.  The  next  step  should  be  the 
implementation  of  tree  data  structures  and  fault  removal  (as  faults  are 
detected)  to  increase  simulator  speed.  Then  signal  state  retention 
should  be  added  to  the  tree  in  preparation  for  sequential  capability. 
Evaluation  of  sequential  systems  and  nominal  delays  should  be  added  by 
implementing  an  event  queue  and  activity-directed  evaluation.  The 
implementation  of  these  capabilities  will  complete  the  development  of 
the  fault  simulator  and  should  be  followed  by  a  thorough  performance 
analysis. 

Once  this  stage  of  development  is  complete,  the  emphasis  should 
shift  to  using  this  fault  simulator  as  a  host  for  test  generation 
research.  Current  research  suggests  that  the  additional  information 
about  a  system  which  is  available  in  the  hierarchy  can  be  used  with 
heuristic  algorithms  and  expert  systems  to  automate  test  generation.  As 
integrated  circuits  get  more  complicated,  brute  force  techniques  for 
test  generation  become  less  feasible.  Greater  emphasis  must  be  placed 
on  test  generation  systems  that  use  intelligence  and  sophistication  to 
reduce  the  computational  overhead  and  produce  higher  quality  tests. 


APPENDIX  A.  SCALD  SOURCE  FOR  THE  FAST  MULTIPLIER 


This  is  the  SCALD  source  for  the  fast  multiplier.  The  listing 
begins  with  the  definiton  of  the  highest  level  and  proceeds  by  defining 
each  module  in  greater  detail  until  the  simulator  primitives  are  called 
at  the  lowest  level. 


MNAME=FASTMULT; 

PARAMETER=L3,L2,L1 ,L0,K3,K2,K1 ,K0, J3 ,J2, J1 , JO , 

13,12,11 ,I0,H3,H2, HI ,H0,G3,G2,G1 ,G0, 
F3,F2,F1,F0,E3,E2fE1 ,E0 ,D3,D2,D1 ,D0, 

C3,C2,C1 , C0,B3,B2,B1 ,B0,A3,A2,A1 ,A0, 
M47,M46,M45,M44,M43,M42,M41  ,M40 ,M39,M38,M37 ,M36 , 

M35 ,  M34 ,  M33 ,  M32 ,  M3 1 ,  M30 ,  M29 ,  M28 ,  M27  ,  M26  ,  M2  5 ,  M2  4 , 
M23.M22.M21 , M20 ,M19 .M18.M17 ,M16 ,M15 ,M14 ,M13 ,M12 , 

Ml  1 ,  Ml  0  ,M9  ,M8 ,  M7 ,  M6 ,  M5  ,M4  ,M3 ,  M2  ,  Ml  ,M0  ,  GND ; 

MULT44 ( LOC=F1 ) ( A3=L3 , A2=L2 , A1 =L1 , A0=L0 , B3=F3 , B2=F2 , B1 =F1 , B0=F0 , 
M7=NUL*000 ,M6=NULJ001 , M5=NUL*002 ,M4=NUL$003 ,M3=NUL* 004 , 
M2=NUL5t005  ,M1  =NULX 006  , MO=NUL$007 , GNDrGND) ; 

MULT44(L0C=F2) (A3=L3 ,A2=L2 ,A1=L1 , A0=L0 ,B3=E3 ,B2=E2 ,B1 =E1 ,B0=E0 , 
M7=NUL$008 ,M6=NUL*009 ,M5=NUL*010 ,M4=NUL$01 1 ,M3=NUL%012, 
M2=NUL$013,M1=NUL*014,MO=NUL*015,GND=GND); 

MULT44(LOC=F3)(A3=K3,A2=K2,A1=K1,AO=KO,B3=F3,B2=F2,B1=F1,BO=FO, 
M7=NUL*016 ,M6=NUL*017 ,M5=NULf 01 8,M4=NUL%019,M3=NUL%020 , 
M2=NUL*021 ,M1=NUL*022,M0=NUL*023,GND=GND) ; 

MULT44 ( L0C=F4 )  ( A3 =L3 ,  A2 =L2 ,  A 1  =L1  ,  AO =L0 ,  B3  =D3 ,  B2=D2 ,  B1  =D  1 ,  BO =D0 , 
M7=NUL$024,M6=NULJ025,M5=NUL$026 ,M4=NUL?027 ,M3=NULJ028 , 
M2=NUL<029  ,M1=NULt030  ,M0=NULit031  ,GND=GND) ; 


A554(LOC=F37)  /•  0  •/ 

( A4 =NUL$  1 20 ,  A3  =NUL*  1 28 ,  A2 =NUL?  1 36  ,  A 1  =NUL*  1 44 ,  A0 =NULf  1 52 , 
B4=NUL$ 121, B3=NUL* 1 29 , B2=NULS 1 37 , B1 zNUL* 1 45 , B0=NUL$ 1 53 , 
S3=NUL$284,S2=NOL*285,S1=NUL*286 ,S0=NUL*287)  ; 
A554(LOC=F38)  /•  1  •/ 

( A4 = NUL< 1 22 , A3 = NUL* 1 30 , A2 = NUL> 1 3  8 , A 1 =  NUL* 1 46 , A0 = NUL* 154, 
B4=NUL$ 1 23 , B3=NUL* 131, B2=NUL* 1 39 , B1 =NUL* 1 47 , B0=NUL* 1 55 , 
S3 =NUL$ 288 , S2=NULJ 2  89 , SI =NUL$  290 , S0=NUL£ 29 1 ) ; 
A554(LOC=F39)  /•  2  •/ 

( A4 =NUL* 1 24 , A3 =NUL$ 1 32 , A2 =NUL* 1 40 , A 1 =NUL* 148, A0 =NUL$ 1 56 , 
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B4=NUL* 1 25 , B3=NUL$ 1 33  *  B2=NUL* 1 4 1 , B1 zNOL* 1 49 , BO =NUL* 1 57 , 
S3=NDLJ292,S2=NULJ293 tSI =NULJ294 ,S0=NDL$295) ; 
A554(LOC=F40)  /•  3  •/ 

( A4  zNUL* 1 26 , A3 zNULjl 134, A2 zNUL* 1 42 , A 1 zNUL* 1 50 , AOrNULt 158, 
B4=NUL!11 27 ,  B3=N0LJ  1 35 ,  B2=NULt  1 43 ,  B1  =NOU  1 51 ,  BO=NULJ  1 59 , 
S3=NUL$296 ,S2=NOL$297 ,S1 zNULt 298 , S0zNUL*299) ; 


A22225(L0C=F6l )  (A3=NUL*008  ,A2zNUL*009  ,A1zNUL*010  ,A0zNUL*01 1 , 

/•  x  •/  B3=NUL%016,B2=NOL%017,B1=NUL*018,BO=NUL%019, 

S4zNUL$ 37  8 , S3  =NULf  37  9 , S2 = NUL*  3  80 , S 1 =  NUL*  3  8 1 , SO = NUL*  3  82 ) ; 
A22225(LOC=F62)(A3=NUL*039,A2=NUL*088,A1=NUtf089,AO=NUL%090, 

/*  y  */  B3=m*047,B2=m*096,B1=NOLX097,BO=NUL*098, 

S4=MULH383,S3=NUU384,S2=NDLit385,S1=NUL$386,SO=NULil387) ; 
A22225(L0C=F63)(A3  zNUtf  26  4 , A2  = NOL$  26  5 , A 1 z  NUL*  26  6 , AO = NULJ  26  7 , 

/•  z  */  B3=NUL$272,B2zNUU273,B1zNULJ274,B0zNDU275, 

S4zNUU388,S3=NULJ389,S2zNUU390,S1zNUL$391  ,S0zNUL*392)  ; 
A2223  5 ( LOCzF64 ) ( A3 =NUL* 1 04 , A2 zNUi *  1 05 , A 1 zNUL* 1 06 , AO  zNULJ 1 07 , 

/•  •  •/  B3=NOL%112,B2zNOL1t113,B1zNDU1l4,BOzNUL%115,CO=NULit099, 
S4 zNOLJ 393 , S3 =N0LJ 394 , S2=N0LJ 395 , SI zNOLj 396 , SOzNOLJ 397 ) ; 
/•  next  level  */ 

A22225( L0C=F80 )  (A3=N0L$ 348 ,  A2zNtJL*349 , A1  =NUL* 350  ,  A0=NUL%351  , 

/•  f  •/  B3=m*346IB2zm$347,B1=NULf352,BO=NUL*353f 
S4 =NDL% 46  0 ,  S3  =M9 ,  S2 =M8 ,  SI  sM7 ,  SO  zM6 ) ; 
A22235(L0CzF79)(A3=NULJ340,A2zN0LJ341  ,A1=NUL*342,A0=NUL$343 , 

/•  e  */  B3=NUL<338lB2=NOLH339,B1=NUW344,BO=NDLX345,COzNUL$460, 
S4  zNULJf  457 ,  S3 =NUL*  4 58 ,  S2zN0L*459 ,  SI  zM1 1 ,  SO =M1 0 ) ; 
A554(L0CzF78)  /•  d  •/ 

( A4zNUU334 ,  A3=N0L* 336  ,  A2zGND,  A1  zNUL*389 ,  AOzGND, 

B4=NULt 335 , B3=N0LJ 337 , B2zGND , B1 zNOL* 390 , BOzGND, 

S3=NUL| 453 , S2zNUL< 454 , SI zNOLJ 455 , SOzNULJ 456 ) ; 

A554(LOC=F77)  /•  c  */ 

(A4=NUL*332,A3=NULt322,A2zNULJ330,A1zGND,A0zGMD, 
B4zNUL*333,B3=MOU323,B2zNUL*331,B1zNUL$388,BOzGND, 
S3=NUU449,S2zNOLJ450,S1zNULJ451  ,S0zNUL*452) ; 


A22235(LOCzF66)(A3=NUL!1004,A2zNOU005,A1zNUL$354,A0zNOL>355, 

/•  1  •/  B3=NULt379,B2zNUU380,B1zN0U38l  ,B0=NUU382,C0zNUL%408, 
S4zNULJ403,S3=NOLJ404,S2zNOU405,S1zNUU406,S0zNOL$407)  ; 
A22235(  LOC=F65)  (A3=NOL*000 ,  A2zNtJL*001 ,  A1  zNUL*002 ,  A0zNCL*003 , 

/•  0  «/  B3  =GND , B2 zGND , B1 zGND , BO zNULJ 378, COzNULJ 403 , 

S4zNUL$398,S3=NOL$399,S2zNUU400,S1zNULJ401  ,S0=NUL*402); 
/*  final  stage  of  adders  */ 

A22225 ( LOCz  F89 ) ( A3  zGND , A2  zNUL$  457 , A 1 zNUL*  45  8 , AOzNULS 459, 

/•  8  •/  B3=NUL$455,B2zNOLt456,B1zNUL$391  ,B0zNUU392, 

S4  zNULJ  46  9 , S3  =M1 5 , S2zM1 4 , SI  zMI 3 1 SO  zMI 2 ) ; 
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A22235(L0C=F88)(A3=NUL*449,A2sNUL*450,A1sNUL*451  ,A0sNUL*452, 

/•  7  */  B3sNUL*447,B2sNUL*448,B1sNUL*453,B0sNUL$454,C0sNUL$469, 
S4 =NUL)t  46  8 ,  S3  =M1 9 ,  S2=M1 8 ,  SI  =M17 ,  SO =M16 ) ; 


• 

A22225(L0C=F81 )  (A3=NULf399,A2=NUL*400,A1=NUL$401  ,A0sNUL*402, 
/•  0  •/  B3sGND,B2=GND,B1sGND,BOsNUL$462, 

S4  =NUtf 46 1 ,  S3 =M47 ,  S2=M46  ,  SI  =M4 5 ,  SO =M44 ) ; 

END; 

MNAME=A22235; 

PARAMETERS  A3,  A2,  A 1,  AO,  B3,B2,B1 ,BO ,C0,S4 ,S3 ,S2 ,S1 ,SO; 

FA( LOC=A22235_1 ) ( A=AO ,B=BO , CINsCO , COUTsNUL* OOO , SUMsSO ) ; 

FA(  L0C=A22235_2)  (A=A1  ,BsB1  ,CIN=NDL$000  ,  COUTsNUtf 001  ,SU»fcS1 )  ; 
FA(L0CsA22235_3) (A=A2,B=B2,CIN=NUL?001 , C0UT=NDLJ002,SOM=S2) ; 
FA( LOC= A22235_4 ) ( A= A3 , B=B3 , CINsNUL* 002 , C00T=S4 , SUM=S3 ) ; 

END; 

MNAME=A22225; 

PARAMETER=A3,A2,A1 ,A0,B3,B2,B1 ,B0 ,S4 ,S3 ,S2 ,S1 ,S0; 

HA(  L0C=A22225_1 )  ( AsAO ,  B=BO ,  COUTsNULjOOO  , SUMsSO ) ; 
FA(L0C=A22225_2)  (A=A1  ,B=B1  .CINsNULfOOO ,COUTsNUL*001  ,SUM=S1 ) ; 
FA(L0C=A22225_3) (A=A2 ,B=B2 ,CIN=NUl*001 ,C0UTsNUL*002 ,SUM=S2) ; 
FA( LOC= A22225_4 ) ( A=A3 , B=B3 , CINsNUL* 002 , CODTr S4 , SUM=S3 ) ; 

END; 

MNAMEsHA; 

PARAMETERS A, B, COUT, SUM; 

X0R2 ( LOCsHAI ) (AsA, BsB, FXORsSUM) ; 

AND2( L0C=HA2 ) ( As A , BsB, FAND=C0UT) ; 

END; 

MNAMEsFA; 

PARAMETER=A,B,CIN, COUT, SUM; 

XOR3( LOCsFAl ) (AsA, BsB, CsCIN, FXORsSUM) ; 

AND2( L0C=FA2 ) ( AsB, B=CIN, FANDsNULjOOO ) ; 
AND2(L0CsFA3)(AsA,BsCIN,FAND=NUL$001); 

AND2( LOCsFA4 ) ( AsA, BsB, FANDsNUL%002 ) ; 

OR3 ( LOC=FA5 ) ( AsNUL*002 , BsNULS  00 1 , C=NUL*  000 , FORs  COUT) ; 

END; 

MNAME=A554; 

PARAMETERS A4 ,A3 , A2 , A1 , AO ,34 ,B3 ,B2 ,B1 ,B0,S3,S2,S1 ,SO; 
FA(LOCsA554_l)(AsB2,BsB1 .CINsBO, 

COUTsNUL^OOl , SUMsNULj 000 ) ; 

HA( LOCsA554_2) (AsB4 ,BsB3 , 

COUTsNUU003,SUMsNULX002) ; 

FA(  LOCs A554.3 )  ( As  A2  ,  BsAI  ,  CINs  AO  , 
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COUT=NUL$005,SUM=NUL*004) ; 

HA( LOC= A554_4 ) ( A=A4 , B=A3 , 

C0UT=NUL*007 ,SUM=NUL$006 ) ; 

HA( LOC=A554_5 ) ( A=NUL* 002 , B=NUL$000 , 

COU  T= NUL$ 008 , SUM=  SO ) ; 

FA( LOC=A554_6 ) ( A=NUL*003 , B=NUL* 001 , CIN=NUL*008 , 
COUT=NUL*010,SUM=NUL*009); 

HA( L0C=A554_7) ( ArNUL$006 ,B=NUL*004 , 

COU  T=  NUL*  0 1 2 , SUM=  NUL$  0 1 1 ) ; 

FA(LOC=A554_8) (A=NUL$007 ,B=NUL*005 ,CIN=NUL*012 , 

COUT=NUL$  014, SUM= NUL*  013); 

HA( LOC=A554_9) ( A=NUL$ 01 1 , B=NUL%009 , 

COUT=NUL$015,SUM=S1 ); 

FAC  LOC= A554_1 0 ) ( A=NUL* 0 1 3 , B=NUL$ 0 1 0 , CIN=NUL* 0 1 5 , 

COUT=NUL*Ol6 ,SUM=S2) ; 

OR2(LOC=A554_1 1 ) (A=NUL$014 ,B=NUL*016 ,C=S3) ; 

END; 

MNAME=PARRAY4X4; 

PARAMETER=X3 , X2 , XI , XO , Y3 , Y2 , Y1 , YO , 

X3Y3 , X3Y2 , X3Y 1 , X3Y0 , X2Y3 , X2Y2 , X2Y 1 , X2Y0 , 

X1Y3.X1Y2.X1Y1 ,X1Y0,X0Y3,X0Y2,X0Y1 ,XOYO; 

AND2( L0C=PA1 ) (A=X3 , B=Y3,FAND=X3Y3) ; 

AND2 ( LOC= PA2 ) ( A=X3 , B= Y2 , FAND=X3Y2 ) ; 

AND2(L0C=PA3) (A=X3,B=Y1 ,FAND=X3Y1) ; 

AND2C  LOC=  PA4 ) (A=X3,B=Y0, FAND=X3Y0 ) ; 

AND2C  LOC=  PA5 ) ( A=X2 , B= Y3 , FAND=X2Y3 ) ; 

AND2C  LOC= PA6 ) ( A=X2 , B= Y2 , FAND=X2Y2 ) ; 

AND2(L0C=PA7) (A=X2,B=Y1 ,FAND=X2Y1) ; 

AND2( LOC=  PA8 ) ( A=X2 , B=YO , FAND=X2Y0 ) ; 

AND2(LOC=PA9)(A=X1,B=Y3,FAND=X1Y3); 

AND2( LOCrPAIO) (A=X1 ,B=Y2,FAND=X1Y2) ; 

AND2C  L0C=PA1 1 ) ( A=X1 ,B=Y1 ,FAND=X1Y1); 

AND2C L0C=PA1 2) (A=X1 ,B=Y0,FAND=X1Y0) ; 

AND2C  LOCrPAI 3) ( A=XO ,B=Y3 ,FAND=X0Y3) ; 

AND2C  LOC= PA 1 4 ) ( A=XO , B= Y2 , FAND=X0Y2 ) ; 

AND2C  L0C=PA1 5) ( A=XO ,B=Y1 ,FAND=X0Y1 ) ; 

AND2( LOC=  PA 1 6 ) ( A=XO , B= YO , FANDr XO YO ) ; 

END; 

MNAME=SARRAY4X4; 

PARAMETER=X3 Y3 , X3Y2 , X3Y 1 , X3Y0 , X2Y3 , X2Y2 , X2Y1 , X2Y0 , 
X1Y3,X1Y2,X1Y1 ,X1Y0,X0Y3 ,X0Y2,X0Y1 ,XOYO, 
Z7,Z6,Z5,Z4,Z3,Z2,Z1 ,ZO,GND; 

WIREC  LOCsSAI ) ( A=XOYO , B=ZO ) ; 

FA(L0C=SA2) ( A=X0Y1 , B=GND, CINsXlYO , C0UT=NUL$004 ,SUM=Z1 ) ; 

FA(  L0C=SA3 ) (A=X0Y2,B=GND, CINsXI Y 1 , C0UT=NULj002 ,SUM=NULJ 003 ) ; 

FAC  L0C=SA4 ) ( A=X0Y3 ,B=GND, CIN=X1 Y2 , COUT=NUL*000 ,SUM=NUL*001 ) ; 

FA ( LOCr  SA5 ) ( A = NUL*  00  3 , B= NUL*  00  4 , C IN= X2Y0 , COU  T=  NUL*  00  9 , SUMr  Z2 ) ; 
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FA(L0C=SA6) (A=NUL$001 ,B=NUL$002 ,CIN=X2Y1 , COUT=NUL$007 , SDM=NULX008) ; 
FA( L0C=SA7)  ( A=X1Y3  .BrNUUOOO ,  CIN=X2Y2 , COUT=NUL$005 ,SOM=NUL* 006 ) ; 

FA( LOC=SA8) ( A=NUL$008 ,B=NUL$ 009 , CIN=X3Y0 , C0UT=NUL$01 4 , SUM=Z3 ) ; 

FA ( LOC= SA9 ) ( A= NUL$  006 , B=  NUL*  007 , CIN= X3 Y 1 , COOT=  NUL*  012, SUM=  NUL$  013); 
FA ( LOC=  SA 1 0 ) ( A= X2Y3 , B=NUL$  00  5 , CIN=X3 Y2 , COO  T=  NUL$  010, SUH=  NUL* Oil); 

FA ( LOC= SA 1 1 ) ( A= NUL*  0 1 3 , B=NUL$  0 1 4 , CIN=GND , COOT=  NOL$  0 1 6  ,  SUM=  Z4 ) ; 
FA(LOC=SA12)(A=NUU011  ,B=NUL$012,CIN=NUL$016,COUT=NOL$015,SUM=Z5); 
FA ( LOC= SA1 3 ) ( A=X3Y3 , B=N0L$0 1 0 , CIN= NUL*  0 1 5 , COUT=  Z7 , SOM=  Z6 ) ; 

END; 

MNAME=MULT44; 

PARAMETERS A3 ,A2 ,A1 ,A0,B3,B2,B1 , BO , M7 , M6 , M5 , M4 , M3 , M2 , Ml , MO , GND ; 
PARRAY4X4 ( L0C=M1 ) (X3=A3 , X2=A2 , XI =A1 , XO=AO , Y3=B3 , Y2=B2 , Y1 =B1 , YO=BO , 
X3Y3=NUL$000 , X3Y2=NUL$00 1 , X3Y 1 =NUL$ 002 , X3Y0=NUL* 003 , 
X2Y3=NUL$004  ,X2Y2=NDU005  ,X2Y1  =NDL$006  ,X2Y0=NOL$007  , 

XI  Y3=NUL$008  ,X1  Y2=NULJf009 ,  XI Y1 =NUL$010  , XI Y0=NUL$01 1  , 
X0Y3=NULj 01 2 ,X0Y2=NUL$ 013 , X0Y1 =NUL$ 014 ,X0Y0=NULX01 5) ; 
SARRAY4X4(L0C=M2)( 

X3Y3=NUL$000,X3Y2=NUL$001 ,X3Y1=NUL*002 ,X3Y0=NUL*O03 , 
X2Y3=NULJ 004 , X2Y2=NUL$ 005 ,X2Y 1 =NUL*006 , X2YO=NOLX 007 , 
X1Y3=NUL*008,X1Y2=NULif009,X1Y1=NUL*010,X1YO=NUL%011 , 

XO Y  3 =NUL$  0 1 2 , XO Y  2 =NUL$  0 1 3 , XO Y 1 =NULX  0 1 4 , XO YO =NUL$  0 1 5 , 

Z7=M7 , Z6  =M6 , Z5=M5 , Z4=M4 ,Z3=M3 , Z2=M2 , Z1 =M1 , ZO=MO , GND = GND) ; 


END; 
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APPENDIX  B.  FAULT  LIBRARY  SOURCE 


This  listing  is  the  source  for  the  fault  library.  All  the  primi¬ 
tives  used  by  the  simulator  must  appear  in  this  library.  The  fault  vec¬ 
tor  entries  are  optional  and  can  be  removed  to  turn  off  fault  simula¬ 
tion. 


PRIMITIVErWIRE 

INPUT  1  :  1  =A 

OUTPUT  1  :  2=B 

DELAY  0 

PRIMITIVErBUF 

INPUT  1  ;  1=A 

OUTPUT  1  :  2=FBUF 

DELAY  1 

FAULTLIST  2  ; 

AO , FBUFO 

1< 

A1 ,FBUF1 

0> 

PRIMITIVES INVERT 

INPUT  1  :  1=A 

OUTPUT  1  :2=ABAR 

DELAY  1 

FAULTLIST  2  : 

AO  ,B1 

1> 

A1  ,  BO 

0< 

PRIMITIVE=X0R2 

INPUT  2  :  1  =A, 2 

=  B 

OUTPUT  1  :  3=FX0R 

DELAY  1 

FAULTLIST  4  : 

A0.FX0R0 

10< 

BO.FXORO 

01< 

AO ,B0 ,FX0R1 

11> 

A1 ,B1 ,FX0R1 

00> 

PR IMIT IV  E= X0R3 

INPUT  3  :  1 =A ,2 

=B,3=C 

OUTPUT  1  :  4=FX0R 

DELAY  1 

FAOLTLIST  8  : 

AO ,FXORO 

100< 

BO.FXORO 

010< 

CO,FXORO 

001< 

BO , CO,FXOR1 

0 1 1  > 

AO ,CO,FXOR1 

1 01  > 

AO.BO.FXOR1 

110> 

AO  ,  BO  ,  CO , FXORO 

1 1 1  < 

A1 ,B1 ,C1 , FXOR1 

000> 

PRIMITIVE=AND2 

INPUT  2  :  1=A,2 

=B 

OUTPUT  1  :  3=FAND 

DELAY  1 

FAULTLIST  4  : 

AO ,BO , FANDO 

1 1< 

A1 ,FAND1 

01> 

B1 , FAMD1 

10> 

FAND1 

00> 

PRIMITIVE=AND3 

INPUT  3  :  1=A,2 

=B,3=C 

OUTPUT  1  :  4=FAND 

DELAY  1 

FAULTLIST  7  : 

A1 ,FAND1 

01 1  > 

B1 ,FAND1 

1 01  > 

Cl ,FAND1 

110> 

AO, BO ,CO,FANDO 

1 1 1  < 

FAND1-1 

0??> 

FAND1-2 

?0?> 

FAND1-3 

??0> 

PRIMITIVE=AND4 

INPUT  4  :  1  =A,2 

=B,3=C, 

4=D 

OUTPUT  1  :  5=FAND 

DELAY  1 

FAULTLIST  9  : 

A1 ,FAND1 

0 1 1 1  > 

B1 ,FAND1 

1 01 1  > 

Cl ,FAND1 

1 101  > 

D1 ,FAND1 

1 1 1 0< 

AO  ,  BO  ,  CO ,  DO ,  FANDO 

1 1 1 1  < 

FAND1-1 

0???> 

FAND1-2 

?0??> 

FAND1-3 

??0?> 

FAND1-4 

???0> 

PRIMITIVE: AND5 

INPUT  5  :  1=A,2=B,3=C,4=D,5=E 
OUTPUT  1  :  6sFAND 
DELAY  1 

FAULTLIST  11  : 

A1.FAND1  01 1 1 1  > 

B1.FAND1  101 1 1  > 

C1,FAND1  1 101 1 > 

D1  , FAND1  1 1 101 > 

E1,FAND1  1 1 1 10> 

AO ,  BO  ,  CO ,  DO ,  EO ,  FANDO  1 1 1 1 1  < 
FAND1-1  0????> 

FAND1-2  ?0???> 

FAND1-3  ??0??> 

FAND1-4  ???0?0 

FAND1-5  ????0> 

PRIMITIVE=NAND2 
INPUT  2  :  1=A,2=B 
OUTPUT  1  :  3=FNAND 
DELAY  1 
FAULTLIST  4  : 

AO ,B0  f FNAND1  1 1  > 

A1, FNANDO  01 < 

B1 .FNANDO  10< 

A1 ,  B1 , FNANDO  00< 

PRIMITIVE=NAND3 
INPUT  3  :  1=A,2=B,3=C 
OUTPUT  1  :  4=FNAND 
DELAY  1 
FAULTLIST  8  : 

AO , BO  f  CO , FNAND1  1 1 1 > 

A1, FNANDO  011< 

B1, FNANDO  101< 

Cl .FNANDO  110< 

A1 ,B1  ,C1 .FNANDO  000 < 

F ANDO-1  0??< 

F AND0-2  ?0?< 

F ANDO-3  ??0< 

PRIMITIVE=NAND4 

INPUT  4  :  1=A,2:B,3=C,4=D 

OUTPUT  1  :  5=E 

DELAY  1 

FAULTLIST  10  : 

AO ,B0 , CO ,D0 .FNAND1  1111> 

A1, FNANDO  01 1 1< 

B1, FNANDO  1 01 1 < 


rr -r. 

v- — a  77  •- 

■  ■  ■  v  •  V  ■  •  ’  *  V  V-  *  V- *1  ■  .  «• 

7*  V'  ^  %  ’A  .  •  \  A  ^ 
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r 

Cl, FNANDO 

D1 , FNANDO 

1 1 01  < 

1 1 10< 

’-.•i 

A1 ,B1 , Cl, D1, FNANDO 

0000< 

FNANDO- 1 

0???< 

FNANDO-2 

?0??< 

FN ANDO-3 

??0?< 

- 

FN ANDO-4 

??70< 

-  * 

PRIMITIVES 0R2 

INPOT  2  :  1=A,2 
OUTPUT  1  :  3=C 
DELAY  1 

=B 

.  \ 

FAULTLIST  4  : 

A1 ,B1 ,C1  00> 

AO, CO  10< 

BO, CO  01< 

CO  11< 

• 

PRIMITIVE=OR3 

• 

INPUT  3  :  1=A,2 

=B,3=C 

•  ”  ■* 

* 

OUTPUT  1  :  4=FOR 

•  _ 

DELAY  1 

.y.'.' 

FAULTLIST  6  : 

r 

.  k.  ^ 

A1,B1,C1,FOR1 

000> 

__  1  , 

■ 

AO, FORO 

100< 

• 

BO.FORO 

OTO< 

«  *  W  ■ 

CO.FORO 

001< 

FORO 

110< 

FORO 

1 1 1< 

y* 

9i 

PRIMITIVEsNOR2 
INPUT  2  :  1  =A,2 

sB 

’  • 

OUTPUT  1  :  3=FNOR 

DELAY  1 
FAULTLIST  4  : 

■  ' 

A1 ,B1 ,FNORO 

00< 

_ _ _ _ 

BO.FNOR1 

01> 

.  « 

AO.FNOR1 

10> 

FNOR1 

11> 

PRIMITIVES NOR3 
INPUT  3  :  1=A,2 

=B,3=C 

-  i 

OUTPUT  1  :  4=FNOR 

• 

DELAY  1 

_  * 

FAULTLIST  7  : 

A1 ,B1 , Cl ,FNORO 

000< 

AO.FNOR1 

100> 

BO.FNOR1 

010> 

d — 

► 

CO ,FNOR1 

001> 

•V 

■ « 

•< 

* 

'  s 

«*1 

_  • 

»  • 

.......  ...... 

FN0R1-1 

FN0R1-2 

FN0R1-3 


1??> 

?1?> 

??1> 
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PRIMITIVE=N0R4 

INPOT  4  :  1=A,2=B,3=C,4=D 

OUTPUT  1  :  5=FN0R 


DELAY  1 
FAULTLIST  9  : 

A1 , B1 , Cl , D1 , FNORO  0000< 
AO ,FN0R1  1000> 
BO.FNOR1  0100> 
CO,FNOR1  001 0> 
DO,FNOR1  0001> 
FN0R1-1  1???> 
FN0R1-2  ?1??> 
FN0R1-3  ??1?> 
FN0R1-4  ???1> 


PRIMITIVES MULT44 

INPUT  8  :  1=A3,2=A2,3=A1,4=A0,5=B3,6=B2,7=B1 ,8=B0 
OUTPUT  8  :  9=M7,10=M6,11=M5,12=M4,13=M3,l4=M2f15=M1,l6=M0 
DELAY  1 

PRIMITIVES A5 54 

INPUT  10  :  1=A4,2=A3,3=A2,4*A1,5=A0,6=B4,7=B3,8=B2f9=B1,10=BO 
OUTPUT  4  :  11353,12*32,13=31 ,14=S0 
DELAY  1 

PRIMITIVE* A22225 

INPUT  8  :  1=A3,2=A2,3=A1 ,4=A0,5=B3,6=B2,7=B1 ,8=B0 
OUTPUTS  :  9=S4,10=S3,11sS2,12=S1 ,13=S0 
DELAY  1 

PRIMITIVE* A22235 

INPUT  9  :  1=A3,2=A2,3=A1 ,4=A0,5sB3,6=B2,7=B1 ,8=B0,9=C0 
OUTPUT  5  :  10=S4, 1 1=33 , 12=S2 ,13*S1 , 14=S0 
DELAY  1 


APPENDIX  C.  SAMPLE  MAIN  PROGRAM 


This  is  a  sample  main  program  to  illustrate  how  the  simulator  is 
called.  The  simulator  is  designed  as  a  set  of  callable  subroutines, 
some  routines  which  perform  10  are  optional.  The  simulator  was  designed 
this  way  to  allow  the  user  to  code  special  purpose  main  programs  to  suit 
the  10  needs  for  each  system  to  be  simulated.  The  main  program  can  be 
coded  to  interactively  interrogate  the  user  for  input  and  simulator 
options  in  a  form  suitable  to  the  user,  and  then  restructure  the  data  in 
the  form  the  simulator  expects.  This  design  also  allows  the  simulator 
to  be  called  from  other  programs  such  as  test  pattern  generators  or 
other  simulators. 


#include  <stdio.h> 

♦include- "• ./lib/struet.h"  /*  simulator  type  definitions  */ 

♦include  n. ./lib/mainglobals.h"  /*  global  variable  declarations  */ 

mainO  { 

int  initsimO,  setobserve( ) ,  evaluateO,  displaylists( ) ; 
int  i,  length,  level,  mod type,  activity; 
char  inline[256]; 
struct  sigvector  vector; 


/*  This  routine  reads  the  fault  library  and  system  descriptions  */ 
/•  then  links  the  two  with  the  functional  procedures.  */ 
initsim( ) ; 

/*  This  routine  interrogates  for  the  pin  numbers  the  user  wishes  •/ 
/•to  observe  fault  behavior.  It  flags  these  pins  so  the  •/ 


/•  displaylists  routine  will  output  faults  propagated  to  these  pins.  •/ 
/•  This  routine  is  optional  vectorflags  is  used  only  by  displaylists  •/ 
setobserve( vectorflags) ; 

while  (1)  {  /•  interactive  10  routine  •/ 

for  (i=0;  i<=MAXSIGS;  i++)  {  /•  Init  the  signal  vector  •/ 


vector . value [ i ] =NOLL ; 
vector. faul tlist[i]=NULL; 


} 

fprintf(stderr, "Olease  input  a  vector:  "); 

if  ((length  =  ge tline( inline, MAXSIGS))  ==  0)  break; 

for  (i=1;  i<=length;  i++)  vector,  valued]  =  inlineti-1]; 

level  =0;  /*  flag  the  outer  level  for  evaluate  */ 

modtype  =  2;  /•  the  outer  level  must  be  a  scald  module  */ 

/*  call  to  the  evaluator,  level  and  modtype  should  be  0,2  */ 

/*  vector  contains  the  input  vector,  activity  is  unused  */ 

/*  scaldroot  is  a  pointer  set  by  the  initialization  •/ 

evaluate(scaldroot,4vector , modtype , level ,&activity) ; 

/*  This  routine  processes  faults  attached  to  the  output  vector  */ 
/•  Only  the  pins  flagged  in  vectorflags  are  considered.  •/ 

/•  The  reporting  is  done  in  terms  of  the  system  hierarchy.  •/ 

displaylists( iveetor , vectorflags ) ; 

} 

fprintf(stderr, "Good-Bye. . .0); 
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